fix(cloud): start the agent session on --no-attach#116
Conversation
On cloud providers (daytona/hetzner/vercel/e2b) the bare `agentbox
claude`/`codex`/`opencode` commands and `agentbox fork` route through
`cloudAgentCreate`, which on `--no-attach` returned before the agent's
tmux session was ever created. The cloud session is created lazily by the
attach step, so skipping attach skipped the agent entirely — the box came
up with no agent running, contradicting the documented behavior ("create
the box and start the agent session, but do not attach"). Docker was
unaffected: it creates the session before the attach check.
Fix `cloudAgentCreate` to call `cloudAgentStartDetached` in the
`attach === false` branch — the same helper the `-i` queue worker uses,
which starts a detached tmux session and verifies it stayed up (fail-loud
on immediate exit / credential rejection). The `<agent> start` subcommand
cloud branches did the same lazy no-op (printing "started lazily on
attach"); they now resolve args first, then start the detached session in
background mode. Cloud now matches docker on every path.
Verified end-to-end: docker `--no-attach` still starts the session
(regression guard), and e2b `--no-attach` now brings up a live, logged-in
claude tmux session where before it created an empty box.
Claude-Session: https://claude.ai/code/session_01PTY4KwAeZdAVvgSWxjpYfs
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 512397c. Configure here.
| binary: args.binary, | ||
| sessionName: args.sessionName, | ||
| extraArgs, | ||
| }); |
There was a problem hiding this comment.
Detached start skips resume args
Medium Severity
New --no-attach cloud paths call cloudAgentStartDetached with raw extraArgs only. The attach path in cloudAgentAttach still adds agentResumeArgs when args are empty for claude/codex, so background create/start can launch a fresh agent instead of resuming the box’s recorded session (e.g. after checkpoint restore or claude start with no post--- args).
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 512397c. Configure here.
cloudAgentStartDetached launched the agent with raw extraArgs only, so a background `agentbox <agent> start <box> --no-attach` (and idle-resumed creates) started a fresh agent instead of resuming the box's recorded claude/codex session — the interactive cloudAgentAttach path applies agentResumeArgs when args are empty, but the detached path did not. Apply the same resume-args resolution in cloudAgentStartDetached so the detached path is symmetric with attach. The `-i` queue path always seeds a prompt (non-empty extraArgs), so this no-ops there. Found by Cursor Bugbot on PR #116. Claude-Session: https://claude.ai/code/session_01PTY4KwAeZdAVvgSWxjpYfs


Problem
On cloud providers (daytona/hetzner/vercel/e2b),
agentbox claude/codex/opencode --no-attachandagentbox fork(which maps background mode to--no-attach) created the box but never started the agent. The agent's tmux session is created lazily by the attach step, so skipping attach skipped the agent entirely — the box came up empty.This contradicts the documented
--no-attachbehavior: "create the box and start the agent session, but do not attach (background mode)." Docker was always correct (it creates the session before the attach check).Root cause
The bare commands and
forkfunnel intocloudAgentCreate, which returned early onattach === falsebefore any session was created. The three<agent> startsubcommands had the same gap and even printed "cloud agent sessions are started lazily on attach" and returned without starting anything.Fix
_cloud-agent-create.ts— onattach === false, callcloudAgentStartDetached(...)(the same helper the-iqueue worker uses) to start a detached tmux session and verify it stayed up (fail-loud on immediate exit / credential rejection), instead of returning early.claude.ts/codex.ts/opencode.tsstartsubcommand cloud branches — resolve args (skip-perms, resume teleport) first, then start the detached session in background mode rather than printing the lazy no-op message.Cloud now matches docker on every path. No docs change needed — the
--no-attachhelp text already describes the now-correct behavior.Verification
typecheck+lintclean;cloud-attach/attach-parsetests pass (18/18).--no-attach(regression guard): box created,claudetmux session live with the TUI running.--no-attach(the previously broken path): box created, process exits 0,tmux has-session -t claudeconfirms a live, logged-in Claude TUI — where before it produced an empty box.https://claude.ai/code/session_01PTY4KwAeZdAVvgSWxjpYfs
Note
Medium Risk
Touches cloud session startup on create/start paths for all three agents; wrong behavior could leave boxes running without agents or fail loudly on credential issues, but scope is limited to
--no-attachand reuses an existing helper.Overview
Cloud
--no-attachnow starts the agent in a detached tmux session instead of leaving the box empty until attach. Behavior matches Docker: the session is created up front; only the host terminal attach is skipped.cloudAgentCreateno longer returns early whenattach === false; it callscloudAgentStartDetached(same helper as the-iqueue worker) to launch and verify the session.The claude, codex, and opencode
startsubcommands on non-docker boxes follow the same pattern: resolve args (skip-perms, resume teleport where applicable), thencloudAgentStartDetachedon--no-attach, with updated outro text instead of the old “lazy on attach” message.Reviewed by Cursor Bugbot for commit 512397c. Configure here.